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Summary 
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standard. 
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DATACAST: THE TRANSMISSION SYSTEM 
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1. INTRODUCTION 

The specification of the UK teletext system^ 
(now also known as CCIR system B teletext) was 
written over twelve years ago. Its prime purpose is to 
carry pages of text for display on a domestic television 
receiver. The system uses a fixed format in the 
interests of efficiency, reliability, ruggedness and low 
cost. There are now nearly thirty million receivers 
world-wide equipped for this system, operating in over 
thirty countries. 

The specification allows for up to 16 lines per 
field to be used for teletext data, but there are 
practical limitations caused by the need for com- 
patibility witb existing receivers. The use of lines too 
early in the field interval can cause the data to be 
displayed on screen during the vertical flyback period 
on some receivers. Use of the later lines can cause a 
flared image at the top of the picture. In the UK 
about eight lines per field are currently used for 
teletext sevices but more are in use in some other 
countries. 

Teletext was designed for receivers capable of 
storing only one page. Indeed, in 1974 it seemed 
doubtful whether manufacturers could afford to 
include even that single page of memory. So the 
teletext service repeats all pages (other than subtitles) 
frequently to allow users freely to choose and acquire 
fresh pages. This means that a resource capable of 
sending 55 000 pages per hour is currently used to 
send perhaps 300 different pages at any one time. 
Now that mass semiconductor storage is so cheap it is 
possible to think of databases being updated by 
teletext, so only new material is sent with occasional 
complete replenishments. Several additions to the UK 
teletext system have been made to assist the use of 
automated storage of multiple pages in a decoder. 
Each page carries a sixteen-bit cyclic redundancy 
check to allow correct and complete reception to be 
tested, and page subcodes are used to ensure that at 
any particular time all pages have unique addresses. 

During 1985 the BBC was approached by 
several organisations interested in the possibility of 
using teletext data lines for carrying data for 
commercial purposes where a one-way one-to-many 
data link is appropriate. This Report describes the 
specification and operation of the Datacast system 
which was designed for this application. Experimental 
broadcasts began on September 10th, 1985. The BBC 
Datacast service was announced on October 3rd, 1985 
and the first equipment built specifically to originate 



these signals was installed at BBC Television Centre 
on March 10th, 1986. In September 1986 the first 
users of Datacast were announced. There are now 
several major users of the service, including the 
London Stock Exchange and a chain of betting shops. 

2. COMPATIBILITY 

When the teletext specification was written in 
1976, 75% of the address codes at the start of the data 
lines were allocated, but the other 25% were reserved 
for future use by requiring that the decoders initially 
produced should ignore them. This is the safest way to 
allow for expansion in a digital system. Later data 
services using different clock rates, modulation systems 
or framing codes would always be liable to interfere 
with existing systems, particularly if decoders are not 
designed with knowledge of ail the possible future 
systems. Such problems may remain dormant for 
many years and then suddenly appear when particular 
combinations of data begin to be used. The only way 
to allow a teletext-like system, with an audience of 
millions, to develop safely is by reserving codes in the 
data channel and using them to introduce new 
services. Ideally these in turn still provide other 
reserved codes for further developments. 

Now that so much decoder behaviour is under 
the control of numerous software writers in different 
organisations rather than a known few integrated 
circuit manufacturers it is becoming even more 
important that specifications are clear and unambigu- 
ous, and that everybody is working to the same 
document. It is also helpful if the broadcaster can 
provide test data to exercise reserved codes to assist 
the detailed checking of decoder functions. In the case 
of teletext we are finding that as new decoders appear 
there are more and more constraints we must put on 
the broadcast signal to avoid causing malfunctions in 
particular decoders. In retrospect it would have been 
preferable to define, perhaps by means of a flow 
diagram, the behaviour of a hypothetical reference 
decoder. 

Most of the reserved codes referred to above 
have since been allocated to functions associated with 
the teletext pages, but 25% of that 25% were preserved 
throughout numerous discussions in national and 
international committees over the last twelve years for 
purposes unconnected with page-organised teletext. 
Some of these are the codes used for Datacast. 

Fig. I classifies the various services currently 
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carried using teletext technology. It indicates the 
distinction between magazine/page-organised teletext 
and services using independent data-lines. These are 
two 'safe areas' on the diagram, outside which fall the 
other variations on the teletext format, such as 
changed framing codes or non-Hamming codes. In the 
outer ring of the diagram are systems using different 
data rates and/or different modulation systems. 



mixed in any way in the transmission sequence, as the 
decoder should see each magazine as a separate data 
channel. This independence is only broken by the use 
of the serial magazine transmission mode which allows 
all incoming page headers, regardless of magazine, to 
be presented as they arrive and so puts an obligation 
on the broadcaster to maintain a meaningful sequence 
when all the page headers are taken together. 



data broadcasting services 



using "system B" teletext format 
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telesoftware 
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datacost 



independent doto - line services 



3. INDEPENDENT DATA-LINES 

Each data-line in the teletext format starts with 
a clock run-in sequence (CRl) and framing code (FC). 
The next two eight-bit bytes, known as the magazine 
and row address group (MRAG), are Hamming-coded 
and each carries four message bits. In the page- 
organised teletext application these eight message bits 
are interpreted as a three-bit magazine number (in the 
range 1-8) and a five-bit row address (in the range 
0-31). 

The 1976 teletext specification requires that 
data-lines with row addresses in the range 24-31 be 
ignored. Subsequently it was decided that row 
addresses 24 and 25 represent an extension to the 
page, intended to be stored with the page and included 
in its cyclic redundancy check. Row addresses 26,27 
and 28 are used, possibly more than once in each 
page, to carry additional information to over-write 
characters or to provide special display attributes. 

All of these row addresses are still associated 
only with the current page of their particular 
magazine. Row address (the page header) is used to 
define the boundaries between successive pages of a 
magazine. 

The data-lines of different magazines can be 
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access services 



full field 
services 



Fig. I - Classification of teletext services. 



Row address 29 is reserved for applications 
where information relating to an entire magazine is 
being sent. Only row addresses 30 and 31 remain for 
applications unrelated to the page and magazine 
structure of teletext. Taken together with their eight 
'magazine numbers' these provide 16 MRAG combina- 
tions which can serve as the addresses of 16 
independent data channels. These can be used in any 
way at any time regardless of the content of the 
teletext service without interfering with the normal 
operation of a conventional teletext decoder operating 
according to the specification. This means that 
independent data-line traffic can be broadcast virtually 
immediately, without disrupting any magazine/page- 
organised teletext services being carried at the same 
time on the same network. 

One of these addresses is used for the 
television service data-line^ and four others are 
currently being used with BBC Datacast transmissions, 
although other formats of signal can also be used here 
without interfering with Datacast. 

It is possible to depict the above allocation of 
magazine numbers and row addresses on a diagram 
with eight columns and 32 rows, Unfortunately this 
leads to confusion when it is pointed out, for example, 
that magazine 8, row 30 does not belong to any 
magazine neither is it row 30 of any page! An 
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alternative diagram is given in Fig. 2, where the 256 
possible MRAGs are presented in terms of the 
contents of their first and second byte. It will be seen 
that the 16 combinations corresponding to the 
independent data-lines are selected by the first byte, 
the second byte having the fixed message bits 1111, 
So a test of the second MRAG byte is sufficient to 
separate ail the independent data-lines from those 
relating to a normal teletext service. 



simplify both the generation and the reception of 
Datacast services in applications where several 
teletext-based services are multiplexed together onto a 
single video signal. It will be seen that the overheads 
have largely been arranged so that they are only 
incurred when they serve a function. It will also be 
apparent that the Datacast packet structure is directly 
applicable to other fixed-length packet systems, such as 
the sound/data multiplex of the MAC/packet family-' 
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Fig. 2 - Interpretation of teletext magazine and row address group (MRAG). 



4. DATACAST PACKET STRUCTURE 

The self-contained nature of the Datacast data- 
line within the teletext multiplex makes it appropriate 
to refer to it as a Datacast packet. 

The Datacast packet format is organised in 
eight-bit bytes as shown in Fig. 3, which emphasises 
how certain information in the early part of the packet 
influences the interpretation of the later part. Moreover, 
each packet stands alone and it can be interpreted 
without reference to others. Both these points, which 
are not generally true of page-organised teletext. 



based on 91 -byte packets. 

The function of the bytes of a Datacast packet 
are now considered in their order of transmission. This 
material should be read in conjuction with the UK 
teletext specification'' where, for example, the 
Hamming code is defined. 

4.1 Data channel group 

The first byte of the MRAG of a Datacast 
packet identifies four possibilities. These can be used 
to distinguish between Datacast services arising at 
independent sources, such as regional contributions. 
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This makes it possible for the same addresses to be 
used by more than one source without contention, 
there is no need for overall control of address 
allocation. 

The data channel group is analogous to the 
magazine number of conventional teletext; the same 
page numbers can be used in different magazines and 
they can be originated independently before combining 
onto a single video signal. Similarly, the data channel 
group number is a component of the complete informa- 
tion necessary uniquely to specify a Datacast service. 

The second MRAG byte of a Datacast packet 
carries the Hamming-coded message bits 1111 indicat- 
ing an independent data-line. 

4.2 Format type byte (FT) 

This Hamming-coded byte controls the inter- 
pretation of later bytes of the packet. The four 
message bits, in transmission order, are: 

- if Datacast format applies, 

- 1 if the RI byte is used later, 

- 1 if the CI byte is used later, 

- 1 if the DL byte is used later. 

If the first of these bits is set to 1 then the 
meaning of the other three is not defined, neither is 
the meaning of any subsequent data in that data-line. 
This allows new formats for use with independent 
data-lines to be defined without requiring the use of 
other data channel groups. 

4.3 Packet address length (AL) 

The first three message bits of this Hamming- 
coded byte indicate how many immediately following 
bytes are Hamming-coded and allocated to the packet 
address. The minimum is none, the maximum is six, 
giving a 24-bit address. The 111 state is reserved to 
extend the address capacity in a way not yet defined. 

The last message bit is set to when the access 
to, decoding and interpretation of this particular 



Fi^. 3 - Structure of a Datacast data-line. 

Datacast service is to be independent of and protected 
from interference by any other teletext-based services. 
This facility is provided in anticipation of some pro- 
posed uses where teletext and Datacast services may 
be used to control access to other services, including 
the extreme option of turning off the decoders. 

4.4 Packet address bytes 

Up to six Hamming-coded address bytes, as 
signalled by the AL byte, follow the AL byte. The 
least significant bytes are sent first. The least significant 
bits within each byte are sent first. 

4.5 Packet repeat indicator byte (RI) 

The RI byte is only present if signalled by the 
FT byte. Only then can the packet be repeated 
unchanged, noting that the RI byte itself does change. 

The first four bits are set to when a new 
packet is sent and this number is incremented modulo- 
16 on subsequent repeats of the identical packet. The 
next three bits are not yet defined. The last bit is set to 
to indicate that no further repeats of that packet 
should be expected, but setting to 1 does not neces- 
sarily indicate that there will be a further repeat. This 
last bit is intended to assist certain decoder strategies. 

4.6 Packet continuity indicator byte (Ci) 

The CI byte is only present if signalled by the 
FT byte. It is an eight-bit number incremented 
modulo-256 with each new packet of the same data 
channel group, address length and address bytes. It 
does not change during repeated transmission of the 
same packet. 

If a CI byte is not signalled the eight-bit 
continuity indicator number is used to modify the 
CRC byte, so there is always a continuity indicator of 
one type or the other. 

4.7 Data length byte (DL) 

The DL byte is only present if signalled by the 
FT byte. The first six bits are a binary number 
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defining how many of the immediately following bytes 
(including dummy bytes) constitute data for delivery 
to the user. The last two bits are not yet defined. Note 
that the next most significant bit will need to be used 
if the Datacast format is applied to the 91-byte 
packets of the MAC/packet family of systems. 

The DL byte is used when it is necessary to 
send an incompletely filled packet in order not to 
delay the transmission of data. Any remaining bytes 
before the CRC are not defined but are still subject to 
the CRC. A DL byte may be set to 0000 OOXX {in 
transmission order) to keep a data service open 
without sending data for delivery. 

4.8 User data byte group 

The remaining bytes in the packet, excepting 
the last two, and further limited by the DL byte when 
present, and excluding any dummy bytes, constitute 
the data carried for the users of that packet. There are 
generally between 28 and 36 user data bytes in a 
Datacast packet. There is no restriction on the coding 
of the user data bytes. 

4.9 Byte transparency 

Although there is no restriction on the coding 
of the user data bytes, it is, at present, necessary to 
eliminate long strings of Os and Is from the 
transmitted data to ensure that it is regenerated and 
decoded reliably. If within any user data byte group, 
taken together with any CI and DL bytes, a sequence 
of eight consecutive 0000 0000 bytes or a sequence of 
eight consecutive 1111 1111 bytes occurs the 
broadcaster will (except where there is no remaining 
byte in the user data byte group) insert a following 
dummy byte which forms part of the CRC but which 
is otherwise ignored by the decoder. The use of 
dummy bytes reduces the length of the user data byte 
group, but only in applications where complete bit- 
sequence independence is required in the user data. 
When the data is enciphered it is, in general, very 
unlikely that such sequences will occur. 

The function described above may later be not 
required. It is therefore recommended that decoders be 
equipped with a simple method of disabling it at a 
later date. 



4.10 Cyclic redundancy check (CRC) 

The last two bytes of the Datacast packet are a 
sixteen-bit cyclic redundancy check on any CI and DL 
bytes and all bytes of the user data group, including 
dummy bytes. The data to be checked, with bits in 
transmission order is, in effect, applied to the circuit 
shown in Fig. 4, the register having previously been 
filled with Os. The gates are modulo-2 adders 
('exclusive-OR'). When the feedback path is disabled 
the basic sixteen-bit CRC in transmission bit order is 
produced at the output. 

It will be apparent that if the basic CRC is 
appended to the input data, the process will compare 
the calculated CRC with the incoming CRC and fill 
the register with sixteen Os. This indicates how real- 
time hardware can be used to check the CRC 
although it is currently more usual to conduct the 
operation in software. 

When the CI bit is set, and an explicit 
continuity indicator is sent, the basic CRC is sent. 
When the CI bit is not set, the eight-bit continuity 
indication is sent by modifying the basic CRC. This 
modification is done at the sending end in such a way 
that the above comparison results in the register 
containing the eight-bit continuity indicator repeated 
twice, with the least significant bit at the right-hand 
end of the bytes in the register. A decoder can then 
extract the continuity indicator from the CRC and use 
a 'flywheel' technique to allow it to interpret the CRC 
correctly during occasional errors or even during 
packet loss. 

This use of a sixteen-bit CRC in every 
Datacast packet assures, with high confidence, that 
any errors will be detected. The decoder will be able 
to indicate whether data is right, suspect or absent. 
The extent of the suspect or absent data can be 
indicated and, where packets are repeated, there is the 
possibility of recovering some of if. 

Practical experience with Datacast transmissions 
shows that under normal conditions fewer than one 
received packet per million fails the CRC check. No 
corrupted packet has yet been seen to pass the CRC 
check. 

16- stage shift register 



Fig. 4 - Generation and checking of 
cyclic redundancy check (CRC). 
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5. STANDARDISATION ASPECTS 

In specifying the data broadcasting system 
described above account was taken of the agreed 
standards for data transmission and several features of 
conventional packet-based systems can be identified. 
However, certain contraints peculiar to the broadcast- 
ing application have also been recognised and these 
too have influenced the Datacast specification. 

One of the advantages of a packet-based 
system is that individual packets can stand alone, they 
contain sufficient information to allow them to be 
checked and sent onward as required, possibly by 
more than one route, and at the receiver they can be 
checked and reassembled, if necessary, into the correct 
order. In the case of data carried in place of lines of 
the video waveform this advantage can only be 
enjoyed if each data-line corresponds to a complete 
packet, because individual data-lines are always liable 
to be inserted, deleted or even rearranged within a 
complex television network. 

The familiar pattern of synchronisation of bits, 
bytes and packets, leading to a packet header 
containing address and control information, followed 
by a data field and terminated by a check word, can 
be seen. The particular way in which teletext-like data 
is multiplexed into the field-blanking interval of a 
television signal already provides very secure bit, byte 
and packet synchronisation. For reasons of compati- 
bility and data security, as discussed in Section 2, 
these same mechanisms are used for Datacast. This 
also allows the integrated circuits already developed 
for the 'front end' of teletext reception to be used 
directly for Datacast. The selection between the 
standard page-organised teletext format and the 
independent data-line format is achieved immedi- 
ately after byte synchronisation, as detailed in 
Section 3. 

The useful length of the packets is very 
restricted. In the case of UK teletext on the 625/50 
system the total of 45 bytes is reduced by: 

bit synchronisation (two bytes), 
byte synchronisation (one byte), 
format selection (one byte), 
channel group selection (one byte), 
cyclic redundancy check (two bytes) 

leaving only 38 bytes for address, control and the data 
itself. 

In a conventional packet system certain address 
and control data fields are often unused, and the space 
wasted is not obvious as all subsequent data is simply 



delayed by a small amount. In the fixed-length short 
packet broadcast system a byte wasted is obviously a 
potential data-carrying byte lost for ever. The FT and 
AL bytes (see 4.2, 4.3) were introduced to allow 
redundant bytes to be eliminated. The implied 
continuity index option (see 4.10) was introduced to 
allow a further byte to be saved. 

Most of these considerations apply equally well 
to the use of the 91 -byte packets in the sound/data 
multiplex of the MAC/packet family'' and it is clear 
that the Datacast format can be applied directly in this 
case. 



6. DATACAST ORIGINATION EQUIPMENT 

Datacast can be added to a video signal at a 
different point to teletext without any flow of 
information between the two although, of course, the 
same television line numbers in any one field-blanking 
interval cannot be used! Because there is sometimes a 
necessary redundancy in the normal teletext output, 
due to the need to repeat page headers to provide a 
page erasure interval, it would be more efficient to 
combine the two in a device that recognises this 
redundancy, but this makes the operation considerably 
more complex and more care would be needed to 
maintain reliability. 

Fig. 5 shows a block diagram of a typical use 
of Datacast, indicating the broadcaster's area of 
responsibility. The Datacast transmission equipment is 
a single unit per network, with reserve available. The 
reserve is selected in such a way that data in course of 
transmission is not lost. The unit accepts inputs from 
six sources, usually via modems over leased lines. 
Source B is shown with conditional access equipment 
(encipherment, key distribution and decoder address- 
ing) used before the signal is sent to the broadcaster 
and after it has been received. Source C comprises 
three sub-services, each with conditional access, which 
are combined before sending to the broadcaster along 
a single line. These sub-services may have different 
addresses or they may contain a sub-addressing facility 
within the data carried by a service using a single 
address. 

The transmission equipment includes a unit for 
monitoring the input data, in particular it counts the 
number of user bytes and packets being sent against 
time of day together with measures of peak bit rate 
and delay through the system. Off-air reception can 
also usefully be analysed. This information is, of 
course, the raw material used in charging the users of 
the service. The Datacast transmission equipment 
developed by BBC Research Department is shown in 
Fig. 6 and may be manufactured under licence. 



(EL-195) 



-6- 



teletext 

and 
'telesoftware' 



network 
video 



B V> 




CI 



C2 



C3 



m 



teletext 
subtitles 



^ 



conditional 
access 
/ equipment 




distribution 

and 
transmission 



datacost 

transmission 

equipment 



off-air 

-«■ 

monitoring 



control, monitoring 

logging and 

billing 




-»- 



Fi^. 5 - Typical Datacasl broadcasting system. 
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Fig. 6 - Datacast transmission equipment 
developed at BBC Research Department. 



Fig. 7 - A commercially produced Datacast receiver. 
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7. DATACAST RECEPTION 

Because the data transport mechanism is that 
of teletext, many of the existing teletext chips can be 
used directly or adapted for Datacast reception. The 
BBC Design and Equipment Department has produced 
a design which has been hcensed to several manu- 
facturers. A typical decoder is shown in Fig. 7. These 
units are, in effect, one-way modems. They have 
power and aerial input, and data output. The channel 
tuning and address are fixed and preselected within the 
unit. 

Some manufacturers have combined the 
decoder with the interpretation and display circuitry 
for a particular user, producing a very compact unit. 
In one example the decoder contains a database and 
users can choose standard pages or compose their own 
pages from that data, which is continuously updated 
by Datacast. In another example a large LED screen 
displays share index information transmitted by 
Datacast. 



function by keyboard or card input. The weakness of 
this system is that anyone who has access to a 
deciphering unit can infer the key by examining the 
reponse to known input data. So, although it is secure 
against casual eavesdroppers, a planned attack will be 
successful. This method may be suitable where all 
decoders for a particular service are under the direct 
control of the service provider. 
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Fi^. 8 - Simple enciphermeiU and decipherment of serial data 



8. DATA SECURITY 

Although it is possible to imagine freely 
available services being broadcast by Datacast the 
majority of the applications are likely to be of a 
commercial nature where it will be necessary to 
prevent a casual user from understanding the message. 
Others may need to be secure against deliberate 
attack. 

There are already techniques available for 
enciphering data over a one-way telecommunications 
link and any of these may be used on a Datacast 
channel. Methods of embedding individual codes 
within decoders in such a way that the decoders can 
be uniquely addressed, enabled, and disabled have 
been developed for Direct Broadcasting by Satellite 
and adapted for Datacast applications*. 

BBC Research Department has developed two 
particular sets of equipment for Datacast encipherment. 
One provides modest security, and rapid synchronisa- 
tion, without needing any extra data signalling 
capacity. The source data is passed through a unit 
where each bit is modified by a function of the recent 
modified bits before onward transmission. That same 
function can be used to decipher the data in a 
complementary unit after the Datacast decoder. These 
operations are summarised in Fig. 8. There is a vast 
number of suitable functions available and the wrong 
functions will give a meaningless output. In effect, the 
function generator is the key to the operation, and the 
key may be changed by physically changing a 
component, or by entering details of the changed 



The second method uses data encipherment 
techniques according to draft International Standards 
based on a 64-bit block cipher. Because the use of the 
well-known and published US Data Encryption 
Standard (DES) is restricted an alternative block 
cipher, particularly suitable for software or VLSI 
implementation, has been devised at BBC Research 
Department. The keys are distributed to the decipher- 
ment units by various control messages inserted within 
the data stream. Each unit has a unique number 
embedded within it so messages can be addressed 
solely to one particular unit when necessary. Methods 
of sharing messages between units, and of sending 
intermediate keys controlling access to other keys, are 
provided in ways similar to those defined for 
Conditional Access television^. 

In equipment to demonstrate this second 
method the entire process is handled in a serial-in, 
serial-out unit based on a microprocessor. A short 
loading control program is held in read-only memory 
and the main decipherment and key management 
program, together with the unique identity of each 
unit, are loaded into non-volatile memory powered by 
a battery. This memory can be loaded in nine seconds 
and the information is held for several years. It is not 
possible to discover the contents of the memory from 
the input and output of the device. The demonstration 
device is shown in Fig. 9, with the cable used to 
intercept the data line. In a practical implementation 
this unit would be made 'tamper-proof by, for 
example, potting it as a solid unit in which the battery 
supply to the memory would be interrupted during 
any attempt to cut it open. Clearly, the control of the 
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Pig. 9 - An 'in-line' Datacast decipherment unii 



software for loading such units is an impKirtant part of 
the security process but, as a virtually infinite number 
of variations of the encipherment algorithm are 
available, different versions can be supplied to different 
users. 

This second method can be used to enable and 
disable individual decipherment units, or groups of 
them, by control messages sent as part of the data 
stream. Any of the proposed methods for implementing 
a 'pay-per-item' service can also be supported. 

9. INTERNATIONAL USE 

Already other broadcasters in Europe and 
elsewhere are planning to use the Datacast system for 
commercial data broadcasting. Organisations operating 
private video distribution systems, involving cable and 
satellite, are also showing interest. At present the BBC 
Datacast transmissions are being distributed, along 
with BBC television and teletext programmes, within 
several neighbouring countries by cable and to certain 
overseas cable companies by satellite. 

Experiments have established that Datacast 
carried in the field-blanking interval travels well by 
satellite, ' as does conventional teletext. It can be 
converted to duobinary coding where necessary in the 
same way as teletext. As indicated above, data can 
alternatively be carried in the sound/data multiplex of 
the MAC/packet family by using the standard packet 
format. 

It is important to identify which network is 
carrying the required data when many sources become 
available, and to specify the network as part of the 
packet address. The sixteen-bit network identification 
code which is carried, for example, in the television 
service data line^ of BBC transmissions, serves this 
purpose. It corresponds to the code 'CHID' in the 



MAC/packet system. Such sixteen-bit codes, which 
are intended to be unique world-wide, have already 
been allocated for networks in the UK. 



10. TARIFF POLICY 

With such a unique resource it is important to 
exploit it in the best possible way as a public service. 
It would be very easy to sell the bulk of the capacity 
to a few users who could afford to pay for using the 
system inefficiently and thereby deny access to many 
small users whose modest needs cannot be met in any 
other way. The specification has been designed to 
support an almost unlimited number of individually 
addressable services and it is hoped that means will be 
provided for handling such uses without undue 
technical and administrative overheads. At the time of 
writing the charging structure for Datacast traffic is 
based on 3.8 UK pence per 1 000 bits. 

11. FURTHER APPLICATIONS 

The principles described above for carrying 
independent data lines by teletext for general applica- 
tions can, of course, be used to provide more specific 
data services associated with the television and teletext 
programmes. In particular, there is growing UK 
interest in a 'programme delivery' service whereby 
suitably-equipped domestic video recorders can be pre- 
programmed to record particular programmes in their 
entirety even when they are not broadcast at a 
scheduled time. In the same way that 'packet 8/30' 
has already been allocated to carrying information 
abotil the television and teletext service, another of 
these independent data lines could be defined for use 
in a programme delivery service. 

It is, however, important to preserve 'coding 
space' for future uses, in the same way as coding space 
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